Penetration testing in practice

Miroslav Ludvik

 Penetration testing often takes place in situation where the management doesn't fully trust the IT department. It is sometimes ordered by the IT department itself to show its excellent work. However, this is not the case covered by this case study.

One day a phone rang in our office that surprised me a bit. The caller introduced himself as a security manager of one big oil company (The sphere of business, identification passwords etc. were purposely changed to make client identification impossible). He said his company is interested in our services and he'd like to have a meeting with us. He spoke mysteriously, he didn't want to tell any details and he wasn't equipped for secure communication.

Within a week the mysterious call turned out to be a request for internal "zero knowledge" penetration test – that is a test which should discover weak points that could be exploited from within the internal network by someone who has no information about the tested network and applications. Further, it was agreed that the subject to test will be only network exploitable weak points. During the contract preparation we were aware that it's not typical contract and that a maximal discretion and an exactness in statements are desirable. The reason is that customer often expects the contractor to take complete responsibility for the effects of testing. In this case it was not possible and we had to explain the impossibility of such responsibility to the customer.

Nobody doubts that every minute of system outage in a bank causes significant losses, it's not so obvious in an oil company. However, the level of loss could be similar because the entire processing line depends on the computer network. I must admit I told to myself "What losses could there be? In the worst-case the oil wouldn't be processed for a few hours"; I was quickly set right by them, however. I was told that it in the worst-case the oil products could leak onto the ground instead of the containers. Better not to think the consequences to the end.

Not only does the testing itself result from the estimate of losses and possible risks but also the contract between the contractor and the customer. It also arises from the nature of the penetration tests that we are dealing with activities which are against most of the instructions and rules for ordinary employees. It's especially necessary to tell who is responsible for what in the contract. Because of the risk of very high possible losses and because we were not able to find an insurance company which would cover the risk, we could not take the responsibility for the risks of testing without detail knowledge of the systems, devices and applications and their configuration. And we could not get these informations because then it wouldn't be "zero knowledge" testing.

Despite of the fact that both contracting parties wanted an exact definition of their responsibility in the contract, this demand showed to be unfeasible. The final contract of course defined the responsibility for situations that could possibly happen, but we unfortunately could not take the responsibility in some cases because we didn't know the configuration of the systems and we couldn't make sure that they are patched with proper security patches etc. The contractual liability for the possible nonavailability of some of the systems was established as follows:

The client is obliged to make a complete backup of all data and configurations and save it to the bank just before the start of testing.

The client will provide an appropriate emergency service which will immediately solve possible breakdowns of individual systems. This emergency service will be provided for all key systems and applications.

The contractor is aware he works in the real-time operation and he will conform the testing method to that fact. He will also act with maximal care.

In addition to other ordinary statutes the contract also stated an independent arbiter who, in case of a problem, will judge if the problem was caused by the contractor (e.g. using inadequate methods) or by the client (e.g. because of an error in configuration, absence of key security patches, etc.).

Both parties approached the testing with responsibility so the above-mentioned statute wasn't used.

Technical background of penetration testing

After more than a week the contract was finished and signed by both parties so we could begin with testing. When I came to the place a small room with two PCs was assigned to me. Each of them was connected to another Ethernet segment and they allowed me to get to a VLAN used by all users. Upon stating my network adapter's address I got an IP address from the range normal users use. These two PCs and the necessary know-how was all equipment I got for the testing. I was also equipped with an attendance system chip card which allowed me to access the room and WC.

I used a desktop PC with Debian unstable Linux distribution with a 2.6 kernel and a notebook with Windows XP and the same Linux distribution as on the desktop for the penetration testing.

The penetration testing itself

Of course I could begin with running a few security scanners (with all vulnerability tests turned on) and base the handwork upon its results. Unfortunately there are companies that just write their report on the basis of these results and then they are finished. I didn't even consider that because I've done this work for a long time. Especially in this environment it would be very dangerous. Some operating systems and applications don't have their network communication done well enough so such behavior could very easily lead to DoS.

There are even such operating systems and applications that could be taken down by a mere nmap. Moreover, such behavior would be in direct contrary to the contract, because it could hardly be referred to as "acting with maximal care". Therefore I started with testing the DHCP configuration. I changed the desktop PC's MAC address using ifconfig (ifconfig is used to configure or show the configuration of a network interface) and tried to connect to the network. And I found the first security drawback right away. Not only did I connect to the network (switch didn't reject me), but I even got an IP address from the DHCP server. And this address was from the very same range as the one I got officially. So I had the same rights and restrictions (for example the same Internet access restrictions). It was the first significant vulnerability because anyone who could get to the active ethernet could browse through the network and access the Internet using a client's address.

The next step was mapping of "living computers" in the user subnet. I did that with a mass ping to these computers. Of course I was aware that there could be a firewall on some of them and they may not reply. Nevertheless I got a broad survey for further orientation. Because I did this mass ping using nmap program with the right options I got also MAC addresses of the computers and the network card manufacturers. I used this information just for orientation because MAC address and therefore also the network card manufacturer could be easily spoofed, although that's not very common. I ran this using cron (system program that runs commands periodically) every 10 minutes to complete the list. Thus it listed even occasionally used computers.

Once I had this list I wrote a simple script which translated all the internal addresses to DNS names. Using another script I got names of the individual devices (host computer names). I went through the list of DNS names and host names and I figured out, for example, that host names of user PCs and notebooks contained the user surname and DNS name PC00x.domain.cz. The client apparently used DNS syntax name.domain.cz for devices in the internal network. Further the list contained some devices with DNS names Printer0x and the same host name. Another group of devices used names of characters from Czech fairy-tales (K�emílek, Amálka, etc.). So I came to a theory that the names are assigned as follows:

• PC00x are user stations;

• Printer0x are network printers;

• characters from fairy-tales are active elements, servers and other important devices.

Then I had two basic alternatives. I could accept this hypothesis and save quite a lot of routine work. But I chose the second one, more time-consuming, but in my opinion the right one and I checked the hypothesis further.

User stations

This hypothesis was also confirmed by the fact that about 90% of devices with DNS names PC00x had Realtek as their network card manufacturer in the list. And Realtek is the most common network card included with the mainboard of user PCs. Then I used nmap to roughly detect the used operating system. There were Windows 2000 everywhere as confirmed by another security scanners (I had to act with maximal care here as well); for example by Nessus. Further, using client programs from Samba package, I got domain name, list of all visible and hidden shares and many additional information that I examined later and used for further research. Among other things I found out that the domain is not Active Directory but is based on NT4 instead.

Printers

First of all I focused on the IP addresses I presumed to belong to printers and I confirmed that using nmap. Common characteristic of network printers, faxes, video conference devices etc. is relatively easy predictability of TCP sequence numbers, which makes it easier to take over an established connection for possible attacker. All devices with the name Printer0x were rated poor by nmap (TCP Sequence Prediction: Class=increments by 800, Difficulty=10 (Easy) or even worse).

I could analyze the verbose mode nmap results and search for the real device manufacturer. It was possible to use more such methods. It's very time-consuming. I chose much simpler approach here that didn't threaten any system. I took advantage of the fact that most devices have the port 80 open. Then it was just enough to connect using Lynx to the individual devices and make sure they are printers. Moreover I found out that 3 out of 11 had default settings so I was able to administer them after reading a short readme from manufacturer. Of course I didn't make any changes, I just documented that for the purpose of further report.

Servers and active elements

I considered the devices with names from fairy-tales to be servers, active elements and other key devices. I could start with running nmap as root on them or even Nessus or other security scanner with all vulnerability tests including DoS turned on. It would be very easy and possibly very fast, if it didn't make any system or application crash. But I couldn't do that because of the contract – the possible risks were too high in my opinion. Therefore I started with nmap like before, but on each computer individually.

It was also important that I didn't run this as root because of the safety, so I got only limited information. For example, nmap didn't tell me the operating system version directly. Anyway I got quite a lot of information much safer way. And I was able to identify the versions of most of the devices more accurately. On those that had port 80 open I used my favorite Lynx (internet source viewer) and I got more information right away.

Next I tried connecting to some other ports of known services like ssh, smtp and others. Upon connecting a banner usually comes up and tells something about the system. It's obvious this banner could be spoofed as well, so I had to check it further. For example the machine called Vochom�rka which offered SMTP to the local network introduced itself as Microsoft Exchange 2000. However, after some testing I figured out that Vochom�rka strictly followed RFC which cannot be said about Microsoft Exchange 2000. A while after I noticed there was http running as well.

After connecting to that service I made myself clear about Vochom�rka. Its appearance as MS Exchange was false, because qmailadmin, which ran there, hasn't been ported to MS Windows yet. It was clear Vochom�rka was running Unix. I looked at the source of the html page to be sure that it's not just an image. Of course I tried to log in with wrong credentials and the source of the error page corresponded to the application. I tried some other tests on Vochom�rka, but without success. The result was that I had indeed found the simple trick of the administrator, but I had not found any weakness that could let me in or even compromise the machine.

Tests on another 6 servers had similar results. But then I encountered a server that looked like a Unix one. The most interesting on it was that it had the port 23 open but the port 22 was closed. This fact led me to a preliminary conclusion that telnet is used instead of ssh to administer this machine for some reason. Using hunt and dsniff programs and thanks to a conceptional mistake in the implementation of the ARP protocol (which maps IP addresses to MAC addresses) I managed to catch the root password even though the network was equipped with switches. The password wasn't trivial and one could hardly guess it – it was "2aFrodisIakum24". But it helped me a lot, because another 3 users had an account on this machine, although their passwords were not stored as plaintext – only the MD5 password hashes were available.

Collisions in MD5 algorithm are discussed much recently, though it's clear that finding a collision is one thing and getting the original string from the hash is another – these things are practically not related to each other. However, I think people are lazy and indisciplined, so I created an anonymous ftp server on my PC, transferred the password file there and ran John the Ripper, a unix password cracking program.

It was about twelve o'clock and I knew that my PC had to work then. I only looked at two switches. It seemed they are fairly secure, they had only the port 22 open. Default login and password didn't work just as arp spoofing. I decided it was time to go home. Seeing that it was Friday, my PC had enough time to crack at least one of the three passwords. When I arrived at work on Monday and looked at "John", I saw it managed to crack two of them. One password was found using dictionary words and their variations, the other one using bruteforce.

Then I was in a situation that in addition to revealing the network structure I gained control of one of the important servers and I had three passwords that were used on it. So I generated another password list using a simple script. It contained solely passwords somehow derived from those three. It wasn't short though.

I could approach every system as if it was isolated and test it separately, but I decided to take advantage of the mentioned people characteristics again and also to exploit the fact that the systems often don't have dedicated administrator. Therefore passwords use to be the same or at least derived from the same base. So I figured it was the time to use the materials gained earlier. I generated possible user names from the most used syntaxes, added two password lists and ran several instances of Brutus program (password trier). The more important instance tried to compromise the NT domain using a dictionary attack. The others' task was to gain access to other sources I had found in the network before (http, ftp, etc.). This method gave me access to the entire NT domain and therefore also to two SQL servers and one ftp server.

Conclusion

During the testing I had found a number of less important security problems as well. For example the stations had a so called "null session" enabled, through which I easily determined the full name of user, all user accounts and even the hardware information. More serious weakness was using SNMP v2 which is not encrypted. Then was the penetration testing finished and it was left to make an understandable output. I endeavored (and I hope I managed to) to be brief at this, surround the text with pictures and, of course, in addition to stating the description of the security weaknesses also state a classification of their severity and proposed solution.

The final report had, including the pictures and essentials, approximately 40 pages. This report was quite critical indeed, but not surprising for the security manager who ordered the testing, because, according to the contract, he was kept posted. In addition to the report I also wrote a management summary – that was two page brief of the report. It contained a short task specification, results and recommendations consequent upon the testing. Considering this document was meant for the management, there were no terms.

Unwanted testing beyond the assignment

As it was said before, at the beginning of the testing I got an access card, with which I could get really just to the one specified room and to the WC. About five days before finish I forgot to take the access card. When I noticed that, already being at the client, I told the entrance reception and I expected the receptionist to phone the security manager and ask what to do with me. That didn't happen. To my consternation I was given an employee card and asked whether I know the way. I told him right that I do and I went to my cabinet. From there I called the security manager a notified him of the arisen situation. Then we went together to investigate the significance of the situation and we found that the only room I couldn't get into is the server room.